1. Field of the Invention
The embodiments of the invention generally relate to computer architecture, and more particularly to computer architecture used for manipulating metrics.
2. Description of the Related Art
In the field of software development, metrics are measurements of a particular characteristic of the software program's performance, efficiency, or state. Various instrumented systems generate different kinds of logs. Each of these logs typically contains metrics that capture the state information of the associated system at various points in time. Such information has significant value from an information systems management point of view. For example, such information could be used to study system behavior, to detect performance bottlenecks, to prevent or recover from faults, for accounting, etc.
However, there is generally a gap between the information that a management application needs and the information which is available in a system log. Thus, it is often necessary to be able to collect and aggregate information from multiple logs available from multiple sources in order to serve the requirements of a management application; i.e., to generate the required information. The aggregation may involve deriving metrics after applying some process to the ones that are available from existing logs. Another related problem involves the format in which the management applications expect the desired information. For example, the format may be different from the format in which the available log was generated. Various instrumentation techniques exist which include technologies such as such as Unix Accounting Utilities (UAU), Application Response Measurement (ARM) Application Program Interface (API), Common Resource Modeling (CRM), z/OS (available from International Business Machines, Armonk, N.Y., USA), Common Information Model (CIM), Simple Network Management Protocol (SNMP) (available from Cisco Systems, Inc., San Jose, Calif., USA), Java® Management Extensions (JMX) (available from Sun Microsystems, Santa Clara, Calif., USA), etc. Apart from these, different software (including operating systems) have their own logging format. As such, it would be unreasonable to expect a generic management application to be able to recognize all such present and future log formats.
For example, the Web Services Level Agreement (WSLA) architecture available from International Business Machines, Armonk, N.Y., USA, is aimed at enabling and enforcing service level agreements for web services. A WSLA engine allows the provider and consumer of the service to specify the service level agreement (SLA) for their particular interaction and be able to monitor it for violations. The SLAs are described in terms of limits on various metrics that can be measured or derived from other metrics.
WSLAs are sufficient for the purposes they were designed for, but while a WSLA is aimed at solving the service level agreement problem for web services, it is not generically applicable to multiple metric producers/consumers and is tied to a set of fixed entities (that are involved in a service level agreement). Moreover, in a WSLA there is generally no distinction between metric definition and metric instances. Therefore, only one value of a metric can be represented at a point in time. This means that no context information can be associated with a metric.
Conventionally, customized software is developed every time there is a need to bridge this gap between the requirements of a management application and the outputs available from instrumented systems. Therefore, there is a need for an improved manner of bridging this gap to allow a generic management application to effectively recognize different log formats and to collect, aggregate, and compose metrics.